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(54) Procede securise de chargement de plusieurs applications dans une carte a m6moire a microprocesseur. 



(57) On organise d'une maniere differente le chargement 
oeptusieurs applications dans une carte a puce en creant 
un ensemble de tables: essentiellement quatre tables. Une 
premiere table dite table des applications permet de creer 
des couples fondamentaux entre des noms d'applications 
et des codes secrets, elle est en principe enregistree une 
fois pour toute, meme deja chez le fabricant de la carte a 
puce. Une seconde table modifiable a volonte dite table 
des tableaux de donnees ? permet a chaque application de 
creer autant de tableaux de donnees que Ton desire. Une 
troisieme table dite table des droits permet d'octroyer, par 
une application, et sur des tableaux de donnees crees, par 
cette application, des droits specifiques lies a des utilisa- 
tions. Une quatrieme table contenant des clefs attach ees a 
une application permet la mise en ceuvre de fonction de 
chiffrement. On montre que de cette maniere on empeche 
a une utilisation de ventr modifier ou lire des informations 
enregistrees dans la carte a puce au titre d'une autre appli- 
cation. L'invention presente par rapport aux solutions de 
I'etat de la technique, I'avantag d'etre plus soupl et de 
permettre une modification ulterieure. 
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PROCEDE SECURXSE DE CHARGEMENT DE PLUSIEURS APPLICATIONS 
DANS UNE CARTE A MEMO IRE A MICROPROCESSEUR 

La presente invention a ete faite en collaboration 
avec 1 ' Universite des Sciences et Techniques de Lille # 
Laboratoires CERIM et LIFL. Elle a pour objet un procede 
securise de chargement de plusieurs applications dans 
une carte a memoire munie d'un microprocesseur , dite 
souvent carte a puce. De telles cartes a puce ont 
typiquement trois types d» utilisation. Dans une premiere 
utilisation d 1 identification elles constituent des clefs 
pennettant a leur porteur d'acceder a un lieu ou a un 
service. Dans une utilisation monetaire, elles sont soit 
prechargees avec des unites representatives d'une 
possibility de consommation chez un emetteur de cartes a 
puce (telecommunications en general), soit 1 1 information 
qu" elles contiennent represente un solde d'un compte 
bancaire. Comme dernier type d 1 utilisation, on note le 
stockage de donnees : par exemple, dans un but de 
gestion de sa sante, chaque individu est muni d'une 
carte dans laquelle son dossier medical peut etre 
enregistre, ou encore la carte peut remplacer une carte 
d'identite. 

La presente invention vise a permettre la 
coexistence, sur une meme carte, de ces differentes 
utilisations, sans que 1' usage de la carte fait pour une 
application puisse nuire a 1 " utilisation de la carte 
pour d'autres applications. Dans ce but, 1 1 invention 
procure un procede securise de chargement des 
differentes applications de maniere a ce qu 1 elles ne 
puissent pas interferer les unes avec les autres. 
L 1 invention couvre aussi la facilite de structuration 
attachee a une application et 1 1 interrogation des 
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donnees par application- De plus, le systeme permet 
d'offrir la possibility aux applications de laisser 
"voir" certaines donnees a certaines applications en 
toute confidentiality. 

On connait un premier mode de gestion de plusieurs 
applications dans une seule carte. On va le decrire 
ci-apres et on montrera que malgre les performances dont 
il dispose, ce procSdS de chargement connu rencontre 
certaines limitations. Le procede de l f invention 
montrera comment depasser ces limitations. 

La figure 1 donne un exemple d'un partage de la 
memo ire d'une carte a puce pour convenir a plusieurs 
applications. Une memoire d'une telle carte a puce est 
dans ce cas divisee physiquement en deux parties 
essentielles. Une premiere partie 1 de description 
contient des descripteurs , une deuxieme partie 2 
comprenant des zones de memorisation pure. Un 
descripteur est representatif d'une application. II 
comporte un certain nombre d f octets en langage binaire. 
Un premier octet 3 est dit octet identifiant. II permet 
de designer 1 1 application. Si, au moment d'une 
transaction avec la carte, on presente un code secret et 
1 1 identification de 1* application on aboutit 
immediatement dans le descripteur pour lequel 
1 • identifiant correspond au code secret presente. 

Un descripteur comporte aussi, a la suite de 
1 1 identifiant, une protection 4. Un premier octet de 
cette protection 4 concerne la protection en lecture des 
mots de la memoire, un autre octet concernant la 
protection en ecriture, un troisieme et un quatrieme 
octet concernant l'effacement ou la mise a jour si par 
ailleurs la technologie (EEPROM) de la carte le permet. 
On pourra admettre par exemple que ces inf ormations sont 
codees sur un bit de 1' octet de protection, valant zero 
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il empeche faction, alors qu'il l'autorise s'il vaut 
un. De meine, en ecriture, on pourra admettre que le 
troisieme bit (ou un autre bit) du deuxieme octet de 
protection interdit 1' ecriture si sa valeur est zero ou 
au contraire l'autorise si sa valeur est un (ou 
eventuellement le contraire). De meme, pour l'effacement 
ou la mise a jour. 

Comme dernidre partie essentielle, un descripteur 
comporte enf in un nombre 5 des mots memoires utilises 
par 1 "application concernee. Ce nombre est code par 
exemple sur deux octets apres les codes de la protection 
4. Une application concernee par un descripteur peut 
ainsi contenir un nombre de mots memoires egal a un 
nombre quelconque : par exemple 18. Pour savoir ou se 
trouvent les mots de la memo ire, dans la partie 2 de 
cette memoire, qui correspondent a cette application, 
une instruction du microprocesseur de la carte a puce 
calcule que la premiere adresse des 18 mots autorises 
est egale a la somme, augmentee de un, des mots alloues 
aux precedents descripteurs dans la liste des 
descripteurs de la carte a puce. La derniere adresse 
autorisee est egale a cette somme augmentee du nombre de 
mots indiques dans le descripteur : c'est-a-dire ici 18. 

Si, dans un exemple, un identifiant a correspondu 
au troisiSme descripteur, independamment de savoir si on 
pourra lire ou ecrire dans les mots memoires concernes, 
on saura que la zone memoire allouee §l 1 1 application 
correspond a celle du descripteur 3, qu'elle est placee 
apres celles allouees a ces descripteurs 1 et 2 
respect ivement, et que sa longueur est limitee par le 
nombre de mots alloues a ce descripteur 3 . 

Les micro-processeurs comportent done actuellement , 
dans leur jeu d" instructions, des instructions 
organisees en sequence et stockees d f une maniere 
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definitive dans la memoire (ROM) de la carte a puce, au 
terme desquelles d'une part on salt reperer une 
application choisie, et d 1 autre part on sait limiter de 
maniere irremediable I'acces a un ensemble alloue de 
mots memo ires. 

Pour creer de nouvelles applications, il est par 
ailleurs prevu dans ce jeu d 1 instructions une 
instruction de creation par laquelle il est possible 
d 1 a j outer un descripteur a la suite des descripteurs 
d€j& presents (dans la mesure oCt la place en memoire le 
permet) , et d 1 allouer a cette application decrite par ce 
descripteur un nombre de mots mSmoires (1& aussi en 
fonction d'une place memoire disponible dans la carte) . 
La zone memoire allouee a une nouvelle application est 
completement independante de celle allouee aux 
precedentes applications. 

Cette technique, avec le jeu d 1 instructions 
associe, tout en etant efficace presente une premiere 
limitation qui est celle d'interdire a une application 
d'aller travailler dans la zone memoire reservee a une 
autre application precedemment enregistree. Ceci est 
comprehensible puisque c'est le but securitaire du 
systeme. Cependant, dans certain cas, il est possible 
que le titulaire d'une application souhaite, dans une 
application complementaire que lui meme programmerait , 
acceder a une ou des zones memoires qu 1 il s 1 est 
prfecSdemment allouSes. ce n'est pas possible. La 

structure n'est pas souple. 

Pour donner un ordre d*idee, on pourrait admettre 
dans une application bancaire qu'un banquier a dej& 
autorise, par une application enregistree et representee 
par un descripteur 1, au titulaire de la carte de 
prelever une certaine somme d 1 argent par semaine sur son 
compte. II pourrait par la suite vouloir autoriser ce 



2673476 



5 

meme titulaire a effectuer des virements, compte a 
compte, a partir du compte bancaire represents par sa 
carte a puce. Cette deuxieme application, dans la 
situation actuelle, doit etre entree completement 
independamment de la premiere, Ceci conduit a une 
duplication de certaines zones memo ires , et a un 
probleme de leur gestion. Le solde present dans une des 
zones memoires d'une application est par exemple affecte 
par un retrait, alors que le solde, en theorie le meme, 
dans une autre zone mSmoire correspondant au virement, 
n'est pas correlativement debite de la somme 
correspondant au retrait. 

Dans ce cas, la solution consisterait pour le 
banquier a supprimer une des applications, et a entrer 
une autre application, en r emplacement , qui comprendrait 
la total ite des instructions des applications 
precedentes. Ceci provoque une perte de place dans la 
carte. Comme par ailleurs on sait que les tailles 
memoires dans ces cartes sont limitees, on comprend que 
cette technique n'est pas sans inconvenient. 

En outre, les derniers octets du descripteur 
renseignent sur le nombre des mots utilisables dans la 
memoire, mais ceci n'est pas tou jours une bonne fagon de 
proceder. En effet, en particulier dans les operations 
de stockage de donnees pures, on peut retenir comme 
longueur de mot memoire, soit des longueurs fixes : par 
exemple 30 octets (chaque octet pouvant etre affecte & 
un caractere) , soit une longueur variable. Mais dans ce 
cas, on doit, apres chaque information enregistr€e, 
faire apparaitre un octet (un caractere) separateur, par 
exemple correspondant en langage ASCII a une etoile ou 
une barre de fraction oblique ou autre. Une telle 
structuration prSsente 1 1 inconvenient qu'elle necessite 
d f etre connue d'une maniere precise par les programmeurs 
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qui utilisent les cartes, ce qui conduit dans certains 
cas a des lourdeurs d' utilisation. Meme pour une 
application tres simple il est necessaire de connaitre 
parfaitement tout le f onctionnement de la carte et du 
5 microprocesseur . 

Par ailleurs, le format en longueur fixe peut, dans 
la plupart des cas, conduire a une perte de place 
systematique du fait d'un sur-dimensionnement des 
longueurs des mots pour palier tous les problemes. 

10 Les problemes de securite ou de droit d ! acces aux 

donnees de la carte sont lies a 1 1 emplacement de ces 
donnees dans la memo ire* 

L 1 invention a pour objet de remedier a ces 
inconvenients et limitations, en proposant une structure 

15 et urie organisation des donnees des applications dans la 
carte completement differente et dont la securite ne 
requiert pas d'imposer aux donnees des places 
particulieres en memoire. Dans cette structure, au lieu 
d'associer comme element indissociable, d'une part un 

20 identifiant relatif a 1 'application, d* autre part des 
conditions de protection, et enfin des allocations de 
zones memoires avec lesquelles les applications 
travaillent, on a prefere organiser les relations entre 
ces differents concepts de maniere hierarchique. 

25 Comme on le verra par la suite, on cree d'abord une 

relation entre les applications, les identif iants, et de 
preference des codes secrets. Cette relation est 
memorisee dans la carte dans une table dite table des 
applications. Ensuite, on enregistre dans une deuxieme 

30 table, dite table des tableaux, les relations qui 
peuvent exister entre une application donnee et un 
tableau de donnees avec lequel cette application 
travaille. Comme caracteristique principale, la creation 
d'un tableau de donnees n'est autorisee que pour un 
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proprietaire d 1 application. Le tableau de donnees 
concerne sera alors dit, dans la suite de cet expose, 
comme appartenant a 1 •application. Enfin, dans une 
troisieme table, dite table des droits, on organise les 
5 possibilites d 1 interaction des differentes applications 
et applications-utilisateur sur les tableaux crees. 

On distingue done ici des classes entre des 
applications, par exemple 1 1 application bancaire, et des 
applications-utilisateur. On verra que pour difference 

10 essentielle, entre les applications et les 
applications-utilisateur dans la table des applications, 
on alloue aux applications une possibility de memoire 
(pour creer des tableaux de donnees correspondant a 
cette application) , alors que les 

15 applications-utilisateur ne re?oivent aucune possibility 
memoire dans ce but. Les applications-utilisateur sont 
obligees pour travailler d'utiliser une partie de la 
memoire qui leur aura ete pretee par une application. 

Comme avantage essentiel, le systeme de 1* invention 

2 0 permet la modification au fur et a mesure des tableaux 
de donnees, la creation et la destruction, par le 
proprietaire d'une application, de ses 

applications-utilisateur, et la delegation, egalement 
par ce meme proprietaire d 1 application, de droits 

25 d'acces sur ses tableaux de donnees a d f autres 
applications ou applications-utilisateur. Les 

applications-utilisateur peuvent travailler sur des 
tableaux de donnees deja presents dans la memoire de la 
carte, dans la mesure oH le titulaire de 1 'application 

30 le permet (table des droits) . 

Par ailleurs, on regie la question des economies de 
place en memoire, en autorisant, dans la table des 
tableaux de donn§es, la possibility systSmatique d 1 avoir 
des enregistrements de longueur variable. 
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L ' invention a done pour objet, un precede de 
chargement et de gestion de plusieurs applications dans 
une carte a puce, caracterise en ce que dans la memo ire 
de la carte a puce 
5 - on cree (CREATE) une table des applications 

(BANQUE, GARAGE, SEC SOC) , 

- on cree (MADE) un ou des tableaux de donnees 
proprifete de ces applications (BANQUE) , 

- on cree (GRANT) des droits octroy ables a des 
10 applications (RETRAIT) sur ces tableaux de donnees 

(TABLE1) , 

et en ce qu ' on autor ise 

- la gestion des donnees contenues dans un tableau de 
donnees en fonction d'une application en cours et des 
15 droits relatifs a cette application. 

Bien que, du point de vue logique, les applications 
et les applications-utilisateur aient une meme 
structure, les conditions d 1 utilisation qui les 
concernent sont differentes. Par ailleurs, 1' ensemble 
20 des operations decrites etant "dynamique" , des actions 
sur les tableaux ou la gestion des applications et 
applications-utilisateur peuvent intervenir dans tout le 
cycle de vie de la carte. 

L 1 invention sera mieux comprise a la lecture de la 
25 description qui suit et a l'examen des figures qui 
1 1 accompagnent . Celles-ci ne sont donnees qu'a titre 
indicatif et nullement limitatif de 1* invention. 

Les figures montrent : 

- figure 1 : la representation dejS. commentee d'une 
30 organisation de la memoire d'une carte a puce dans 

l'Stat de la technique ; 

- figure 2 : la representation schematique d'une 
carte a puce selon 1 • invention et son utilisation comme 
outil de transaction ; 
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- figures 3 a 5 : des representations precises 
respectivement des tables d 1 applications, des tables de 
tableaux et des tables de droits ; 

- figure 6 : des particular ites d 1 organisation des 
donnees dans la table des tableaux ; 

- figure 7 : la consequence de 1 1 organisation de la 
table des tableaux sur le rangement des donnees dans une 
memoire de donnees de la carte a puce ; 

- figures 8, 9 et 10 : des organ igraxnmes de 
creation respectivement de chacune des tables selon 
1 1 invention . 

- figures 11 et 12 : des organ igraiomes d 1 actions 
possibles sur le tableau de donnees. 

La figure 2 represente une organisation schematique 
d f une carte a puce selon 1» invention. Cette carte a puce 
10 comporte, sur un support, un circuit electronique 
muni de moyens d^change avec le monde exterieur, non 
representes mais de type connu (metallisations de 
contacts) . Ce circuit electronique comporte un 
microprocesseur 11 et une memoir e de donnees 12 (dans un 
exemple .cette memoire de donnees 12 est du type EEPROM, 
c'est-a-dire qu f elle est programmable et eff arable) . La 
puce de la carte a puce comporte aussi une memoire 
programme 13 (ROM) qui contient les instructions du 
microprocesseur propres a 1« invention, Selon ce qui a 
ete indique precedemment, dans la memoire de la puce on 
reconnait, en plus de la mSmoire de donnees 12, la 
presence d'une table des applications 14, d f une table 
des tableaux 15, et d'une table des droits 16. On 
remarque aussi la presence, ce qui sera explique plus 
loin, d'une table 17 des clefs de chiffrement. La table 
17 etant particuliere, elle peut aussi etre definie 
complement a irement dans la table des tableaux 15. Ceci 
permet une transmission chif free des donnees lues dans 
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la meraoire 12. Le microprocesseur 11 est relie au 
differentes memoires 12 a 17 par un bus de donnees et 
d'adresses 110. Une architecture type d'un 
microprocesseur est par ailleurs decrite dans le livre : 
5 " Comprendre les Microprocesseurs" de Daniel Queyssac, 
Editions Radio, France 1983. 

Lors de 1' utilisation d'une telle carte a puce 10, 
celle-ci est introduite dans un lecteur 18 comportant 
lui meme un microprocesseur (non represente) 

10 susceptible d'executer avec la carte 10 un programme 19 
a I'aide d'un clavier 20, d'un moniteur de visualisation 
21 et d'une machine 22. 

Par exemple, comme represente sur le moniteur 21 
pour une application bancaire, un operateur agissant sur 

15 le clavier 20 peut provoquer un retrait, et done 
provoquer l f execution d'une partie du programme 19, par 
lequel la machine 22 lui distribuera des billets de 
banque 23. En meme temps, le lecteur enregistrera dans 
la carte a puce (ou dans un systeme centralise de 

2 0 gestion non represente) le debit du compte 

correspondant . 

On a indique d'une maniere schSmatique sur I'ecran 
du moniteur 21 la presence de plusieurs applications 
possibles : une application BANQUE, une application 

25 .GARAGE, une application SECSOC de securite sociale. On 
aurait pu faire figurer d'autres applications par 
exemple, TELECOM pour telecommunication ou autre. 
L'interet de 1' invention vient de ce que differents 
operateurs, differents emetteurs dit encore 

30 proprietaires d 1 application, sans relations 

contractuelles les uns avec les autres, peuvent utiliser 
un meme support et ce sans risque que les actions 
effectuees par un des proprietaires d f applications ou 
des utilisateurs ne viennent inf luencer les donnees 
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enregis trees dans des tableaux de donnees appartenant S 
un autre proprietaire d« application (on mesure 
facilement le risque que cela comporterait dans le 
domaine bancaire) . 
5 Par ailleurs, pour 1 •application bancaire, on 

montre sur l'ecran du moniteur 21, plusieurs 
utilisations possibles : f igurent par exemple les 
utilisations RETRAIT, VIREMENT, VISUALISATION. On 
distingue done bien hierarchiquement, d'une part les 

10 applications, et d' autre part des 

applications-utilisateur . Comme on le verra plus loin, 
ces applications et ces applications-utilisateur sont 
toutes enregistrees dans la table des applications* 
Cependant la difference qui les departage reside dans le 

15 fait que les applications peuvent creer et exploiter 
(lecture ecriture, mise S jour, effacement) des tableaux 
de donnees alors que les applications-utilisateur ne 
peuvent que les exploiter. Cette exploitation est 
controlee de deux manieres. D'une part, une allocation 

2 0 memoire autorise l f insertion d'enregistrements, ou de 
lignes, dans un tableau de donnees si cette allocation 
n'est pas nulle. D 1 autre part la table des droits peut 
permettre & cette application-utilisateur d'inserer 
(INSERT), d'enlever (DELETE), de mettre a jour (MODIF) , 

25 ou seulement de selectionner (SELECT) un enregistrement 
dans un tableau de donnees sur lequel elle a regu ces 
droits. 

La memoire de la carte etant partagee par plusieurs 
applications, lors de la creation des applications et 
30 des applications-utilisateur, une grandeur maximum de 
memoire utilisable est definie pour chaque application 
ou application-utilisateur. Dans son principe, cette 
information de grandeur est memorisee dans un compteur 
present dans la table des applications. lors de 
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1'adjonction de donnees dans une ligne d'un tableau de 
donnees par une application ou une 

application— utilisateur, le contenu du compteur est 
diminue du nombre de caractere inseres. Dans le cas 
5 d'une destruction de donnees dans une ligne du tableau, 
il est augmente du nombre de caractere supprimes. Au 
lieu de caracteres, on peut aussi specifier, dans 
I 1 allocation memoire, un nombre de lignes de 
renseignements : la taille de la ligne pouvant etre 

10 libre (dans la limite de la place disponible) . 

Dans la description qui va suivre, on va presenter 
chacune des tables de 1' invent ion, en precisant d'une 
part leur structure, et d' autre part les ordres auxquels 
elles repondent : c'est-S-dire les instructions que le 

15 microprbcesseur est charge d'executer (a 1' exclusion de 
tout autre) pour les creer et les modifier. 

La figure 3 montre la table 14 des applications. 
Cette table comporte essentiellement quatre colonnes. 
Une premiere colonne est la colonne NOM D 1 APPLICATION. 

20 Une deuxieme colonne est la colonne MOT DE PASSE de 
1 1 application. Une troisieme colonne est la colonne 
TAILLE MEMOIRE UTILISABLE. D'une maniere preferee, bien 
que cela ne soit pas obligatoire, la colonne mot de 
passe de 1 1 application est elle meme partagee en deux 

25 parties, une premiere partie comportant le code secret 
lui meme et une seconde partie, situee apres ou avant la 
premiere, contenant un nombre maximum d'essais que l f on 
est susceptible d'effectuer pour presenter le code 
secret afin de pouvoir entrer dans 1 'application. De 

30 meme que pour les tableaux de donnees, de preference, la 
table des applications aura des colonnes dont la 
longueur est variable. 

Par exemple le nom de 1 'application et le mot de 
passe de 1 'application sont limites en longueur. Le 
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nombre d'essais de presentation du code secret, et 
l'espace memoire utilisable seront memorises, en 
longueur fixe, par une valeur contenues respect ivement 
dans un et deux octets. On verra plus loin comment il 
est possible de prevoir des tallies variables. 

En rappel de ce qui est indique pr ecedemment , on a 
presente dans cette table six enregistrements 141 a 
146 : les trois premiers representent des applications 
proprement dites avec une taille de memoire utilisable 
differente de zero, les trois derniers representent des 
applications-utilisateur avec elles aussi une taille 
memoire utilisable non nulle. Ces 

applications-utilisateur ne pourront pas ulterieurement 
creer des tableaux de donnees. Pour les distinguer des 
applications, elles comportent dans une quatrieme 
colonne une indication ici U, mentionnant leur type : 
application-utilisateur. Les applications proprement 
dite comportent en correspondance une indication A. Bien 
entendu, d'autres symboles sont utilisables, ce qui 
compte c'est de dif f erencier . 

Pour simplifier, on a attribue a chaque 
application, un mot de passe : pour 1 1 application BANQUE 
il s'agit du mot de passe FORTUNE, pour 1 1 application 
GARAGE il s 9 agit du mot de passe AUTO, pour 
1 • application securite sociale il s»agit du mot de passe 
SANTE. Pour les trois utilisations respectivement 
RETRAIT , VIREMENT, VISUALISATION, les mots de passes 
sont USE1, USE2, et USE3 . 

La figure 8 montre I 1 operation de creation de la 
table des applications. Cette creation est normalement 
effectuee par le fabricant de la carte a puce ou par une 
entite emettrice ayant obtenu aupres du fabricant le mot 
de passe d'une application SYSTEME. Pour simplifier la 
description on considerera que c^st le fabricant de la 
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carte a puce qui fait cette operation. On appellera 
cette operation, par habitude f personnalisation de la 
carte, cette operation consiste a introduire dans la 
carte les applications BANQUE, SECSOC et GARAGE. Celui 
qui realise la personnalisation attribue des codes 
secrets de preference par un procede aleatoire, aux 
applications. Ces applications pourront lors de la 
premiere utilisation de la carte changer ce code (CHANGE 
CODE) et s'attribuer un code qui ne so it connu que 
dalles seules. 

Avant que les cartes soient livrees nues, avant 
leur personnalisation avec les differentes applications, 
on peut considerer neanmoins qu'elles comportent, du 
fait de !■ existence des instructions du microprocesseur 
d'une part et de I 9 organisation en tables d 1 autre part, 
une application systeme avec laquelle il va etre 
possible de programmer la carte. 

Le programme systeme comporte une instruction 
PRESENT qui doit etre suivie dans sa syntaxe du nom de 
l 1 application concernee. Pour faciliter la gestion 
interne du systeme, la table des applications contient, 
au moins au debut, une application particuliere appelee 
SYSTEME. Le systeme contient le microprocesseur, la 
memoire et le programme realisant les f onctionnalites de 
l 1 invention. Ce programme est contenu en ROM. Dans le 
reste de cette description on parlera d 1 instructions du 
microprocesseur pour qualifier les f onctionnalites du 
systeme. L 1 instruction PRESENT a pour objet de chercher 
a comparer un code secret dejS enregistrS dans la carte 
a un code secret propose par l'operateur avec un clavier 
comme le clavier 20. 

En pratique, l'operateur introduit la carte dans le 
lecteur 18 et envoie avec le clavier 20 les instructions 
precedentes : PRESENT SYSTEME. Puis le code secret, 
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SECRET, est entre au clavier, et 1 1 operateur valide 
cette entree. Une verification est alors entreprise pour 
savoir si le code secret SECRET entre par le clavier est 
le meme que le code secret SECRET precedemment 
enregistre dans la carte, Le code secret precedemment 
enregistre dans la carte est le code secret fondamental 
de la puce : il est normalement stocke dans une partie 
speciale de la memo ire. Cette partie n'est pas 
accessible a l'exterieur de la carte. Seul le systeme de 
la carte y a acces. En cas d f echec de la verification, 
on about it sur un programme de rejet. 

Le programme de rejet peut comporter 1 ' autorisation 
de representer le code secret a nouveau, autant de fois 
au total que cela est permis pour l 1 application. Par 
exemple, dans le cas de 1 1 application systeme on a le 
droit de ne presenter qu'une fois. Pour assurer cette 
fonction, 1 1 instruction PRESENT du microprocesseur 
comporte dans I'ordre les actions suivantes : 

1) le chargement du nombre de presentations dans un 
registre interne du microprocesseur, 

2) 1 1 incrementation d'un compteur de tentatives a 
chaque tentative, 

3) la comparaison du compteur et du nombre charge, 

4) le branchement conditionnel sur un rejet 
definitif ou une autre tentative. Le compteur de 
tentatives fait partie de la carte a puce. 

Le programme de rejet comporte done un compteur de 
tentatives, parametrable par le nombre autorise de 
presentation du mot de passe, qui, lorsqu'il est plein 
provoque le rejet proprement dit de la tentative. En 
pratique, ce rejet de la tentative peut conduire le 
systeme exterieur (lecteur 18) a retenir def initivement 
prisonniere la carte 10 et d'une maniere connue en soi a 
l'orienter vers un receptacle d'ou son porteur ne peut 
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la retirer. 

Si la verification a ete faite avec succes, a ce 
stade de la fabrication , done chez le fabricant de 
cartes a puce, on ne peut executer qu'un ordre : l 1 ordre 
CREATE. Par cet ordre CREATE, on peut enregistrer toutes 
les applications et les applications-utilisateur qu'on 
veut. Avec cette operation, le fabricant peut inserer 
des applications dans -la table 14 des applications qui 
est aussi celle des applications-utilisateur. Pour cela, 
il suffit d'envoyer & la carte 1» ordre CREATE, suivi du 
nom de 1 'application, du code secret attribue a cette 
application, de I'espace memo ire utilisable par cette 
application et du noiabre autorise de tentatives 
infructueuses de presentation de code secret pour cette 
application. Pour distinguer les 

applications-utilisateur des applications on ajoute a 
cet ordre soit un parametre A pour les applications et U 
pour les applications-utilisateur. Ou encore, de 
preference, la carte dispose d'un couple d'ordres CREATE 
APPLICATION et CREATE APPLICATIONUSER dont les 
parametres sont les memes que pour le CREATE precedent, 
mais qui placent alors automatiquement les indications A 
ou U respectivement . On entre ainsi les enregistrements 
141 a 146. Lorsque toutes les applications des 
utilisations sont creees dans la table 14, on peut 
envoyer une instruction CLOSE avec le clavier 20. 

Cette instruction CLOSE a pour objet de faire 
basculer, par exemple d'une maniere definitive, la 
possibility d 1 inserer des applications avec 1' ordre 
CREATE APPLICATION. En effet, si le fabricant ne 
connait pas toutes les applications au moment de la 
personnalisation, on pourra plus tard et a condition que 
1* ordre CLOSE n'ait pas ete lance, en refaisant un 
PRESENT SYSTEME suivi du bon code secret, inserer 
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d'autres applications, L'ordre CLOSE permet de fermer 
cette fonctionnalite en invalidant 1 1 application 
SYSTEME. En fait 1 1 application SYSTEME est alors tout 
simplement enlevee de la table des applications* Elle ne 
peut plus ensuite etre reconnue par la carte. Par 
contre, les applications peuvent garder le droit de 
creer des applications-utilisateur avec l'ordre 
CREATE-APPLI CATION USER. 

Cette invalidation est, sur le plan materiel , 
obtenue par le claquage d'un fusible, ou par le 
basculement irremediable d'une cellule memo ire d'une 
memo ire de type EPROM d'un etat logique dans un autre. 
L 1 operation CLOSE peut etre suivie d'une operation 
REBOOT de redemarrage de la carte : 1 1 alimentation 
electrique de la puce doit etre coupee puis restauree. 
Dans ce cas, la table 14 des applications est figee 
def initivement. Si on ne lance pas 1 1 instruction CLOSE 
la carte n'est pas verrouillee. 

On a represents sur la figure 3, 1 1 association des 
clefs de chiffrement avec les applications. Ceci 
signifie que la table 14 des applications peut 
comporter, comme cinquieme colonne, une colonne 
representative des clefs de chiffrement. Dans ce cas, 
les clefs de chiffrement doivent etre indiquees une fois 
pour toute : elles ne sont jamais modifiables puisque la 
table 14 peut ne plus etre accessible apres l'ordre 
CLOSE. En pratique, et contrairement a ce qui est 
indique pour simplifier sur la figure 3, il y aura une 
table 17 des clefs de chiffrement dans laquelle seront 
associees une a une les applications et les clefs de 
chiffrement. La table 17 des clefs de chiffrement etant 
modifiable : on pourra modifier pour chaque application 
la valeur de la clef. 

Les chif frements dont il est question ici sont des 
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chif frements de types DES ou RSA connus par ailleurs 
pour lesquels le parametrage du chif f rement necessite 
une clef, dite secrete quand elle n'est connue que par 
un utilisateur et qu'elle n'est dependante que d'une 
seule utilisation, ou dite publique lorsqu'elle est 
commune a tous les utilisateurs de 1 'application. Le 
chif f rement d'une donnee consiste a modifier cette 
donnee selon un tel algorithme ainsi parametre. Le 
microprocesseur est muni d'une maniere connue des 
instructions necessaires a 1' execution d'un tel 
algorithme. Par ce principe, le microprocesseur de la 
carte peut mettre en oeuvre les clefs de chif f rement 
attachees a une application sans que les applications 
aient a partager des clefs. La table des clefs doit 
contenir a chaque lighe la clef et 1 ■ application a 
laquelle elle est destinee. 

La figure 4 montre la table des tableaux de donnees 
15 • Cette table n'est pas fermee def initivement dans la 
carte : elle peut etre completee ou modif iee tout le 
long de la duree de vie de cette carte. Pour simplifier, 
on a indique que l'ordre execute par le microprocesseur 
pour creer un enregistrement dans cette table est un 
ordre MADE. Cet ordre MADE est associable a un ordre 
REMOVE par lequel il est possible de supprimer un 
enregistrement. La table des tableaux 15 est montree 
sous une forme theorique dans la figure 4 et sous une 
forme reelle dans la figure 6. Elle comporte 
essentiellement, confer figure 4, 1 ' association d'un nom 
d f application, d'un nom de tableau et d'une description 
des colonnes du tableau de donn§es que I'on cree. De 
plus, de maniere preferee la table des tableaux 15 
comporte des colonnes relatives a des pointeurs, ici 
trois types de pointeurs, ainsi qu'une colonne relative 
au nombre de colonnes du tableau de donnees lui meme, et 
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enfin une autre colonne relative au type du tableau, T 
pour tableau et V pour vue , represents par 
1 1 enregistrement • 

Sur la figure 4 on remarque qu*on a affecte a 
chacune des applications principales un tableau, 
respectivement TABLE 1 a 1 « application BANQUE, TABLE 2 a 
1 1 application GARAGE, TABLE3 a 1« application SECSOC. On 
voit qu'il n'y a pas de tableau propres aux 
applications-utilisateur indiquees precedemment, parce 
que ces dernieres etant munies de 1" indication U il leur 
est interdit de creer des tableaux . Ces 
applications-utilisateur ne peuvent qu'inserer, 
modifier, ef facer ou select ionner des donnees dans des 
tableaux deja crees (si des droits out ete accordes en 
ce sens) . 

La table 15 des tableaux de donnees est creee au 
fur et a mesure par les proprietaires des applications 
selon 1 1 organ igrarame presente sur la figure 9. Pour 
creer un tableau, par exemple TABLE1, dans la table 15 
des tableaux de donnees, un proprietaire d 1 application 
execute, comrae precedemment, un ordre PRESENT, dans le 
cas present "PRESENT BANQUE". Dans ce cas, le 
microprocesseur selon l'algorithme deja etudie 
precedemment demands que puisse etre verifiee la 
concordance du code secret, associe a BANQUE dans la 
table 14, ici "FORTUNE", avec un code secret entre au 
clavier • En cas de succes de cette verification, on peut 
executer les ordres MADE ou REMOVE. 

Tous les ordres, y compris 1* ordre PRESENT, sont 
executes alors que le microprocesseur de la carte est 
en RECEPTION D* ORDRE : il attend une sollicitation 
exterieure. Des qu*un ordre est envoye, (par exemple par 
le clavier) cet ordre est d^bord analyse par 
comparaison aux ordres possibles pour le 
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microprocesseur. Si 1' ordre est errone, interdit ou mal 
re9U, a l f issue de l 1 analyse la carte se remet en 
attente de RECEPTION D 1 ORDRE - Dans le cas contraire, 
l 1 execution est commencee. En ce qui concerne l 1 ordre 
PRESENT il provoque 1 1 inscription dans un registre du 
microprocesseur, dit registre de 1 * application 
courante, du nom de 1 1 application pour laquelle cet 
ordre PRESENT est lance. Par exemple, ce registre 
d 1 application courante est charge des noms SYSTEM ou 
BANQUE dans les deux exemples represent^s Figures 8 et 9 
respectiveiaent. Apres ce chargement, la comparaison du 
code secret s 1 ef f ectue et provoque 1 1 inscription , en cas 
de succes, d'une indication OUI, similaire, dans un 
registre de code secret du microprocesseur. Ensuite, le 
microprocesseur se remet en attente d* ordre. Pour 
executer les ordres MADE ou REMOVE, le microprocesseur 
verifie apres l 1 analyse de ces ordres que 1 • application 
(BANQUE) pour laquelle ces ordres ont ete lances est 
associee, dans la table 14 des applications, a une 
indication de type A permettant la creation de tableau 
de donnees. Si 1" indication est U la creation ou la 
suppression sont interdites. 

Avec l 1 ordre MADE, le programme automatique li€ a 
cet ordre porte le contenu du registre d 1 application 
courante a l'endroit, dans la table 14, du nom de 
l 1 application. C'est automatique. Dans l'exemple ou on a 
affaire a 1 'application BANQUE , ce nom d 1 application est 
porte automat iquement par le microprocesseur dans la 
colonne correspondante . On doit ensuite specifier, selon 
un ordre predetermine, le nom de la table et definir la 
table et les colonnes. La definition de la table 
comporte essentiellement la designation du nombre de 
colonnes et, pour chaque colonne, la designation du type 
de la colonne : colonne a longueur variable ou S 



2673476 



21 

longueur fixe, II faut aussi indiquer la longueur 
maximum de la colonne (que se soit a longueur variable 
ou a longueur fixe) . De maniere preferee cette longueur 
sera comprise entre 1 et 255- Enfin, il faut donner a 
chague colonne du -tableau de donnees un nom. La 
description des colonnes doit se faire en autant de fois 
qu'il y a des colonnes. On definit egalement le type de 
la table T pour table et V pour vue. On verra plus loin 
a quoi correspond ce type. 

A la fin de l'ordre MADE le systeme retourne en 
reception d'ordre. Si on execute un ordre REMOVE, on 
supprime un enregistrement dans la table 14 a condition 
que l'on soit proprietaire de 1 'application : 
c'est-a-dire qu'on soit susceptible., de rentrer au 
prealable a la fois le nom de 1 1 application et le code 
secret attache a cette application. La table des 
tableaux de donnees cree une relation de propriete entre 
le proprietaire de 1 1 application et le tableau* 

La figure 6 montre, d'une maniere plus detaillee, 
comment est constitute la table 15 des tableaux de 
donnees. De maniere a ne pas perdre de place, cette 
table des tableaux de donnees comporte des indications 
tendant a compacter le stockage de donnees dans la 
memo ire 12 de donnees. En regardant le haut de la figure 
6, on distingue trois premiers pointeurs : les pointeurs 
XX, YY, et ZZ. Ceci signifie que chacun d'eux est decrit 
sur deux octets. Chaque pointeur represente une adresse. 
L'exemple montre juste en-dessous du haut de la figure 6 
permet de se faire une id£e de la signification des 
differents elements. Ainsi, le premier pointeur XX 
marque 1* adresse relative, dans la partie de la memoire 
12 qui contient la table 15, de la fin de 
1 * enregistrement qui est commence par ce pointeur. 

Comme on le verra plus loin, 1 1 enregistrement en 
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cause dans I'exemple comporte cinquante buit caracteres 
et par consequent le code XX comporte I'adresse 59. Ceci 
signifie que pour aller regarder une description d'un 
tableau de donnees suivant il faut parcourir cinquante 
5 neuf octets supplementaires. Ceci permet rapidement au 
microprocesseur de verifier quels sont les tableaux de 
donnees auxquels il peut avoir acces pour une 
application concernee. 

Le deuxieme pointeur YY donne I'adresse du premier 

10 enregistrement stocke dans la memoire de donnees qui est 
decrit selon le tableau de donnees etudie. Par exemple, 
si YY vaut 200 la premiere information enregistr^e dans 
la memoire de donnees 12 selon la structure du tableau 
de donnees etudie se trouve a I'adresse 2 00, voir figure 

15 7. Le troisieme pointeur ZZ indique I'adresse du dernier 
enregistrement relatif au tableau. Compte tenu de la 
description du tableau en cause et du fait qu'il n'y a 
qu'un enregistrement, cette adresse ZZ vaut aussi ici 
200 comme YY (Figure 7) . 

20 A la suite des pointeurs, sur un caractere, on 

indique le nombre de colonnes de la table. Dans le cas 
de* 1' application bancaire, ce nombre de colonnes est 
egal a 7 (voir figure 4) . Puis on indique le type du 
tableau, lui aussi sur un octet. Dans le cas present, il 

25 s'agit d'un tableau, on indique alors une lettre T. S'il 
s'agissait d'une vue on aurait fait apparaitre une 
indication v (ou autre) . On indiquera par ailleurs 
quelle difference il y a entre les tableaux et les vues. 
Puis on indique le nom du tableau. Ici, d'une maniere 

3 0 preferee, on fait prec§der l 1 indication du nom du 
tableau d f un octet dont la signification est le nombre 
de caracteres (d 1 octets) de ce nom de tableau. 
S'agissant du tableau TABLE 1 dont le nom comporte six 
caracteres, on portera dans cet octet la valeur 6. Le 
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nom du tableau est alors donne sur six octets. On 
remarquera qu'on peut accepter tous les caracteres 
standard, sauf des caracteres correspondant a des 
caracteres de controle du microprocesseur , mais que par 
ailleurs un nom de tableau sera interdit s'il existe 
dSja pour une autre application. L'ordre MADE realise 
cette verification. Le nom de 1 •application dans le 
tableau de donnees pourra etre entrS lui aussi en etant 
precede d'un octet dont la valeur est egale au nombre de 
caracteres de ce nom de 1 ' application. Dans le cas 
present, on a aussi choisi 6, de ce fait les noms 
d 1 applications dans la table 15 ne peuvent avoir que six 
caracteres. Si 1 1 inscription du nom de 1 9 application est 
automat ique, on pourra reprendre ce nom tel qu'il existe 
dans la table 14 , c^st-a-dire en longueur fixe ou en 
longueur variable. Dans ce dernier cas, on reporte aussi 
sa longueur. Puis, autant de fois qu'il y a de colonnes 
dans le tableau de donnees, on indiquera, sur un 
caractere le type de la colonne, sur un autre caractere 
la longueur de la colonne, et enfin, precede de son 
nombre de caracteres, le nom de la colonne. Dans 
I'exemple represents sur le bas de la figure 6, on a 
represents sept colonnes avec a chaque fois un code "1" 
representatif d'un type de colonne a longueur fixe. 
Cette longueur fixe elle meroe etant fixe egale a 9 pour 
les trois premieres colonnes, a 3 pour la quatrieme 
colonne, a 9 pour la quatrieme colonne, a 15 pour la 
sixieme colonne et a 9 pour la septieme colonne. Puis 
les noms de ces colonnes sont donnes a chaque fois en 
etant precede du nombre de caractere dans ces noms. II 
s'agit la de renseigner le nom, le prenom, la rue, le 
numero, la ville, le numero de compte, et le solde 
bancaire d f un individu titulaire de la carte. L'ordre 
MADE permet aussi au microprocesseur de verifier que la 
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taille memoire est plus petite que la taille memoire 
allouee. Pour cela, il se sert des longueurs maximums 
indiquees. Leur somme soit etre infer ieure a la taille 
allouee. 

La figure 7 montre, dans la memoire de donnees 12 
de type EEPROM f les enregistrements correspondants . On 
reiaarque qu'on a choisi ici des enregistrements a 
longueur fixe, mais on pourra preferer choisir comme 
precedemment des enregistrements a longueur variable, ce 
qui per met, pour des mots courts, de compact er la zone 
occupee dans la memoire 7. Le caractere separateur entre 
les mots a longueur variable est done induit dans 
l 1 invention 1) par la structure de description, et 2) 
par la valeur de l 1 octet qui precede. Un utilisateur qui 
programme sa carte (dans la mesure ou I s application le 
lui permet) n'a done pas a se preoccuper de ce 
probleme. 

On va etudier maintenant la table 16 dite table des 
droits. Dans cette table, un proprietaire d 1 application, 
par exemple une banque proprietaire de 1 •application 
BANQUE, va pouvoir octroyer a des 

applications-utilisateur , RETRAIT , VIREMENT , 

VISUALISATION, des droits d 'utilisation SELECT, INSERT, 
MODIF, DELETE sur des enregistrements de sa table ici la 
TABLE1. Autrement dit, un utilisateur qui mettra en 
oeuvre une application-utilisateur pourra effectuer des 
transactions sur les donnees. Ces transactions sont 
autorisees selon le mode decrit dans cette table des 
droits. Pour remplir la table 16, on effectue, confer 
figure 10, une meme suite d 9 operations . On lance l f ordre 
PRESENT, associe a 1 1 application concernee : par exemple 
PRESENT BANQUE. Puis on prSsente le code secret : 
FORTUNE. 

En cas de succes, on peut, avec un ordre de 
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creation, dit GRANT, creer des droits, ou les revoquer 
avec un ordre d'annulation REVOKE. Dans une operation 
d 1 octroi de droit, on designe d'une part le tableau sur 
lequel on octroie les droits, ensuite le nom de 
1 1 applications-utilisateur pour laquelle ces droits sont 
octroyes, et enfin le type des droits octroyes. Avec 
l'ordre GRANT le microprocesseur verifie, a l*aide de 
la table 15, que le tableau (par exemple TABLE1) 
concerne est bien lie a l 1 application (BANQUE) au titre 
de laquelle on octroie les droits. Cette verification 
utilise le nom de 1 1 application courante chargee dans le 
registre pour acceder a la table 15. Les droits octroyes 
peuvent etre codes sur quatre octets, un premier octet 
concerne la lecture et correspond a une selection, les 
trois autres correspondant, respectivement et dans 
l'ordre, a une insertion de donnees, a une modification 
des donnees, ou a une suppression des donnees. 

Ces droits correspondent aux ordres vus plus haut. 
Tout proprietaire d 1 application, proprietaire du tableau 
de donnees associe, peut entrer a tout moment des 
nouveaux droits sur ces tableaux dans la table des 
droits 16 ou en enlever. 

Pour le chiffrement, le fonctionnement est le 
suivant. Au moment oil, au titre d'une utilisation (par 
exemple RETRAIT : figure 3), des donnees sont extraites 
de la memoire de donnees 12, elles sont chif frees par un 
algorithme automatique de chiffrement RSA (ou autre) 
propre au microprocesseur parametre par la clef (CLEF1) 
de I 1 application ou de l 1 applications-utilisateur en 
cause. En consequence, quand ces donnees sont transmises 
de la carte 10 au lecteur 18, elles le sont dans un etat 
chif f re. Bien entendu, le lecteur comporte un meme 
algorithme de chiffrement et connalt, par ailleurs, la 
clef (CLEFl) relative a cette application ou 
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application-utilisateur pour dechiffrer les informations 
transmises. De cette fagon, une application peut 
autoriser une transaction sur les donnees d'un tableau 
qu'elle gere sans craindre de revelation. 

On va decrire maintenant la structure des 
instructions du microprocesseur qui lui permet 
d'executer tous les ordres qui sont SELECT , INSERT, 
MODIF et DELETE* 

Pour executer les ordres SELECT, INSERT, MODIF ou 
DELETE, on execute deja comme vu precedemment un ordre 
PRESENT. Dans le cas present, cet ordre PRESENT sera 
suivi du nom de 1 'application-utilisateur (ou aussi de 
1 'application) pour laquelle ces ordres sont a executer. 
II est egalement suivi de la presentation du code secret 
affecte. En cas de succes, le nom de 
1 1 application-utilisateur est porte dans le registre de 
1 1 application courante et I 1 indication OUI est portee 
dans le registre de code secret. Pour ne pas avoir a 
paraphraser dans la description 1' ordre des operations, 
on se reportera aux dessins concernes. 

L 1 ordre SELECT peut etre lance de la maniere 
suivante. Sa syntaxe comporte SELECT, suivi du nom de la 
table, et suivi d'un ou plusieurs criteres de selection. 
Un critere de selection comporte un nom de colonne, un 
operateur et une valeur. L'operateur peut etre : egal, 
different, superieur, inferieur, inferieur ou egal, ou 
super ieur ou egal. Les criteres de selection peuvent 
etre multiples. Dans ce cas, la syntaxe de 1' ordre 
SELECT comporte tout simplement, a la fin et se suivant 
les uns les autres, les differents criteres. La figure 
11 montre 1 1 organigramme de l 1 ordre SELECT. Dans cet 
organigramme on verifie que les selections sont 
correctement indiquees. En fin de selection, le resultat 
des selections est stocke dans un registre de selection. 
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Le fait que 1 1 application a (ou n*a pas) des droits sur 
le tableau de donne est extrait de la table des droits 
16. L ■ existence du tableau de donnees, et, dans ce 
tableau de donnees, d'une ou des colonnes ayant les noms 
specifies est extrait de la table 15 des tableaux de 
donnees. Une fois que la ou les donnees selectionnees 
ont ete rangees dans le registre de resultat on peut 
fa ire avec cette ou ces donnees toute operation de type 
connu. 

L» ordre INSERT, figure 12, possede les memes etapes 
antecedentes que l 1 ordre SELECT avant A. La syntaxe de 
cet ordre comporte cet ordre INSERT, suivi a la file de 
toutes les valeurs a inscrire, dans 1" ordre oxi elles 
doivent etre inscrites. Pour executer cet ordre, le 
microprocesseur verifie que 1* allocation memoire de 
1 1 application et que la taille memoire utilisable est 
suffisante. Les zones de la table 14 oil sont rangees ces 
tailles memoires utilisables sont des zones ef fagables 
et modif iables, de preference de type EEPROM. En effet, 
apres 1' insertion, la valeur enregistrSe dans une telle 
zone, pour 1 1 application concernee est decrementee de la 
place occupee par la taille de l 1 insertion qu^n vient 
de faire. Ceci explique qu'une application-utilisateur 
dont la taille memoire utilisable est nulle (des le 
depart ou par suite d f execution d f insertion) ne peut pas 
effectuer d 1 insertion dans le tableau de donnees. 

L 1 ordre DELETE est du meme type que 1* ordre INSERT, 
sauf qu^l fonctionne a l'envers. Dans ce cas, le 
compteur est increments a 1' issue. Cependant, pour 
eviter qu'une application-utilisateur, qui n»a des le 
depart aucune taille memoire utilisable, ne puisse en 
acquerir une sur un tableau de donnees, on verifie au 
prealable, dans la table des droits 15 que l'effacement 
est autorise. Cette verification est du meme type que la 
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verification du droit a executer I'ordre d 1 insertion. 

L'ordre MODIF de mise a jour comporte la meme 
syntaxe que I'ordre de selection suivie du nom d'une 
colonne puis d'une valeur. Ceci signifie qu'on place la 
5 nouvelle valeur, dans la ou les lignes select ionnees, a 
l'endroit de la colonne specif iee. La mise a jour peut 
aussi permettre de mettre & jour plusieurs colonnes 
differentes, correspondant neanmoins a des memes 
criteres de selection. 

10 Les vues V sont des sous-tableaux. Elle permettent 

d 1 avoir acces directement a des enregistrements qui 
correspondent dans un tableau de donnees a des 
selections sur des donnees. Les vues sont declarees, 
dans la table 15 des tableaux de donnees de la meme 

15 fagon que les applications ou applications-utilisateur. 

La seule difference porte sur les specifications des 
colonnes qui s 1 appar entent f dans leur cas, a une 
selection. Ces specifications de colonnes comporte done 
d'une part le nom du tableau de donnees (par exemple 

20 TABLE2) sur lequel porte la selection et d 1 autre part, 
la selection elle meme. Cette selection est indiquees 
dans les memes termes que la syntaxe de I'ordre SELECT 
vu precedemment. Dans la table 15 , les 
applications-utilisateur concernes par les vues peuvent 

25 recevoir des droits de selection et de modification mais 
de preference pas d 1 insertion ni d *ef f acement. 
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REVENDICATIONS 



1 - Precede de chargement et de gestion de 
plusieurs applications dans une carte a puce, 
caracterise en ce que dans la memo ire de la carte a puce 

- on cree (CREATE) une table des applications 
(BANQUE, GARAGE, SEC SOC) , 

- on cree (MADE) un ou des tableaux de donnees 
propriete de ces applications (BANQUE) , 

- on cree (GRANT) des droits octroyables a des 
applications (RETRAIT) sur ces tableaux de donnees 
(TABLE1) , 

et en ce qu 1 on autorise 

- la gestion des donnees contenues dans un tableau de 
donnees en fonction d'une application en cours et des 
droits relatifs a cette application. 

2 - Procede de chargement et de gestion de 
plusieurs applications dans une carte a puce, 
caracterise en ce que dans la memoire de la carte a puce 

- on cree (CREATE) une table des applications 
(BANQUE, GARAGE, SEC SOC) en affectant a chaque 
application un code secret d'acces (FORTUNE, AUTO, 
SANTE) et une allocation memoire, 

- on cree (MADE) une table de tableaux de donnees 
en associant un ou des tableaux de donnees (TABLE1) a 
chacune des applications (BANQUE) , 

- on cree (GRANT) une table de droits octroyables a 
des applications (RETRAIT) sur ces tableaux de donnees 
(TABLE1) , 

et en ce qu'on autorise 

- la creation de tableaux de donnees ( TABLE 1) pour 
une application (BANQUE) si on presente avec succes le 
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code secret (FORTUNE) associe a cette application et si 
l 1 allocation memoire pour cette application le permet, 

- la creation de droits sur des tableaux de donnees 
(TABLE1) si on presente avec succes le nom de 
1 'application (BANQUE) pour laquelle on a cree cette 
table et/ou le code secret (FORTUNE) de cette 
application, et 

- la gestion des donnees contenues dans un tableau en 
fonction de 1 1 application en cours et des droits 
octroyes relatifs a cette application. 

3 - Procede selon la revendication 1 ou la 
revendication 2 , caracterise en ce qu 1 on cree dans la 
table des applications des applications et des 
applications-utilisateur, une application disposant du 
droit de creation (CREATE) d 1 applications-utilisateur , 
du droit de creation (MADE) de tableaux de donnees, et 
du droit d'octroyer (GRANT, REVOKE) des droits a des 
applications ou applications-utilisateur sur ses propres 
tableaux de donnees, une application-utilisateur ne 
disposant d'aucun de ces droits. 

4 - Procede selon I'une quelconque des 
revendications 1 a 3, caracterise en ce qu"on cree une 
table de clefs de chiffrement associees chacune a une 
application pour n'autoriser le transfert de donnees 
contenues dans la carte que sous une forme chiffr§e 
dependant d'un algorithme de chiffrement parametre par 
cette clef • 

5 - Procede selon l'une quelconque des 
revendications la 4, caracterise en ce que, dans la 
table des applications, on affecte a chaque application 
un nombre maximum d'essais de transactions avec la carte 
dans cette application. 

6 - Procede selon l'une quelconque des 
revendications 1 a 5, caracterise en ce que, dans la 
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table des tableaux on indique comme description pour 
chaque tableau au mo ins un des elements suivants: 

- le nom de 1 1 application proprietaire du 
tableau, 

- le nom du tableau, 

- le nombre de colonnes du tableau, 

- le type du tableau, 

- les adresses, dans la memoire, des donnees 
relatives a ce tableau, 

- l'adresse du debut de la description du 
tableau suivant, et 

- pour chaque colonne du tableau, le type de 
la colonne, la longueur de la colonne, et le 
nom de la colonne. 

7 - Procede selon la revendication 6, characterise 
en ce que, dans la table des tableaux de donnees, pour 
chaque nom de tableau, d 1 application, ou de colonne on 
fait preceder ce nom par un nombre representatif du 
nombre de caracteres de ce nom. 

8 - Procede selon l'une quelconque des 
revendications la 7, caracterise en ce que, dans la 
table des tableaux de donnees on cree un tableau de 
donnfees en lui affectant automatiquement comme nom 
d 1 application proprietaire une information 
representative du nom de 1 'application pour laquelle on 
a presente avec succes le code secret. 

9 - Procede selon l'une quelconque des 
revendications la 8, caracterise en ce que, dans la 
table des droits on indique comme description pour 
chaque enregistrement ou ligne au mo ins un des elements 
suivarits : 

- le nom du tableau, 

- le nom de 1 1 application ou de 

1 ' application-utilisateur ayant obtenu des 
droits , 

- les droits obtenus. 
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